Work process management

docuRob ® Workflow platform was implemented based on many years of research and development work, the starting point of which was the OfficeObjects® system software and the results of the standardization work of the Object Management Group association in the field of the BPMN 2.02 notation. An additional important starting element for work on the new platform architecture was the implementation of the Topic Maps model (ISO 23250) used to model the semantic resources of the modeled processes.

docuRob ® WorkFlow platform is an implementation of the BPMN 2.02 specification extended with capabilities such as process ontology management based on the TopicMaps standard (ISO/IEC 13250) and our own Business Process Query Language (BPQL).

docuRob® software platform additionally includes the integrated products docuRob ® ObjectManager , docuRob ® eForms and docuRob ® OntologyManager . The docuRob ® software integrated with the Angular web environment and the Java programming language, supported by a mature business process design methodology, provides a strong foundation for the implementation of large IT systems based on a process architecture.

The application areas of our software are business organizations, administrative units and research institutions. The basic application areas of IT solutions using our software tools are:

• Automation of business processes and group work
• Research process management
• Document flow management
• Integration of distributed IT systems
• Monitoring industrial processes ( digital twin )
• Project Management Automation

Control flow

The basic element of workflow management is the definition of control flow. docuRob ® WorkFlow provides eight basic constructs for the definition of control flow:

• Starting point – starts the process, most often related to an event,
• End point – ends a process or one of its paths.
• Transition with condition – establishes the order between activities. If a condition is defined, the transition is performed only if the condition is met,
• Sequence – activities in a sequence are performed sequentially (completion of the previous activity starts the next activity),
• Parallelization – activities belonging to two parallel paths in a process are executed in parallel. This construction involves two control flow operators: splitting (AND-SPLIT) and joining (AND-JOIN),
• Alternative – only the actions belonging to one of the alternative paths will be executed. Each path has an associated condition for executing this path and at most only one of them can be satisfied. This construction involves two control flow operators: splitting (XOR-SPLIT) and joining (XOR-JOIN),
• Event - An action or situation that is detected by software and may require a response from the system. Examples of events include mouse clicks, keystrokes, signals from peripheral devices, changes in system state, and messages from other programs.
• Option – actions are performed depending on the fulfillment of the condition of each path. It is possible for more than one condition to be fulfilled. Two control flow operators are associated with this construction: splitting (OR-SPLIT) and joining (OR-JOIN),
• Subprocess – an activity may be another process (subprocess).

Data flow

Another important aspect of process definition is the definition of data flow. docuRob®WorkFlow provides flexible mechanisms for defining the following data objects that are passed between elements of the related process model:

• Process (input/output) parameters – a process can be seen as a so-called black box. In this case, the process receives some input data, executes, and returns the results of that execution.
• Attributes/process variables – to memorize the data processed within the process, the system provides the ability to define process attributes. An attribute can be of a simple type (text, number, logical value, date, etc.) or of a complex type (XML document). A given attribute can be stored directly in the process repository or outside the process management platform, in an external system. In the latter case, only a reference to a given attribute is maintained in the process container and when it is necessary to read it, the appropriate service (also SQL query) is called, returning the appropriate value.
• An attribute can be multi-valued . In this case, each value is stored under a different key. Attributes are grouped within a process container.
• Parameters of applications called within the activity – just like for a process, each activity can have input and output parameters. These parameters are passed to the application called for the given activity.
• Mapping rules – Business Process Query Language (BPQL) is used to define the flow between process parameters, its attributes and application parameters. This approach allows for the expression of complex mappings in the process.

Assigning Work Participants

The proper assignment of work participants is an important element of the definition of process activities of the User and Manual types . The docuRob® WorkFlow platform provides advanced mechanisms for assigning activity participants based on the BPQL language. Using this language, you can determine workers based on information about users, organizational structure, competencies and roles, process execution history, statistical data or other specific data existing outside the work process management system. In particular, the docuRob®WorkFlow platform provides the following selection definition possibilities:

Static selection of performers – the performer of the action can be given by name (login),

Selection based on organizational structure (hierarchical structure) – participants can be defined by the specifications of the organizational unit they belong to, the position they hold, or the competences they possess. The selection of the participant can also be carried out on the basis of information about the employees' subordination relationship.

Role-based selection – another way is to use information about the roles assigned to process users to select the right participant.

Selection based on functional user groups (horizontal structure) – the docuRob®WorkFlow platform enables the organization of employees of a given institution/company into groups of people with specific competences or responsible for performing a specific task, e.g. manufacturing a product, organizing a tender offer, or performing a specialist assessment. Dynamics means that these groups can be organized during the institution/company's operations depending on specific needs.

Assigning participants based on the work process execution history – the docuRob®WorkFlow platform allows you to refer to the process execution history when defining the people who are to perform the task. For example, if we want the information about acceptance to reach the person submitting the application after the supervisor's decision, we must refer to the work process execution history by specifying, for example, the following BPQL rule: "this task will be given to the person who performed the first stage of work (i.e. submitted the application)".

Taking into account ad-hoc decisions during the execution of the process – there are often situations for which we cannot determine in advance who is to perform a given activity. In such a case, the docuRob®WorkFlow platform allows for making Select decisions , i.e. determining during the execution (and not defining) of the process, who will handle the next activity from the list of previously selected people.

Task execution by the first person from the group – in the case of such work organization, where a given group of employees handles a group of tasks together (e.g. several service points and one queue), the possibility of taking the task by the first person who reports readiness to perform it is particularly important. This mechanism can also be used to avoid a situation when a task is sent to a person who is absent or partial compensation of the load (the first free person takes the task).

Task execution by more than one person – this option is particularly important when we want a specific stage of work to be performed by a group of people. For example, when we consider the process of devirusing computers, where each employee must run the same antivirus program and send the results to the administrator, without the possibility of performing the devirusing by more than one person we are not able to express this in the process definition. The method of performing the devirusing one by one by each employee as a separate stage of work is also not a solution due to the difficulty in expressing the number of stages of work. This number would depend on the number of employees, which may change during staff changes.

Creating complex participant selection conditions – often the participant selection is more complex than those listed above. In such a case, the system offers the possibility of defining a complex BPQL expression selecting, for example, "an employee in a given organizational unit, currently burdened with less than 7 tasks, working in our organization for more than 5 years". The functions included in the expression can be freely embedded.

Adding new user functions - at any time it is possible to register a new function in BPQL defined for the needs of a specific system (e.g. determining the current reserve of days off for a given employee).

Changing the person performing the task – sometimes it happens that the person who was assigned to perform the task is not able to complete it (e.g. they were delegated to other tasks or are simply not present at work). This causes the aforementioned process instance to not be continued. The solution to such a problem is to change the person performing the activity.

Calling the application

In the work process, an application is called to perform a given activity. The docuRob®WorkFlow platform allows the application to be called both in a user task and automatically. In the first case, the application supports a graphical user interface. In the second case, it is an application represented by a service (program). In support of calling applications, the system provides the following possibilities:

Adapters for manual activities – within this interface it is possible to call various service adapters providing a graphical user interface used by the process users. docuRob ® platform provides standard services such as electronic forms, object repository and software managing the system ontology. Building applications in web environments such as Angular or React , or in standard programming languages is supported by the RestAPI of docuRob ® platform products .

Adapters for automatic actions - within this interface it is possible to call various service adapters such as: Java language class or API of used applications published as Rest or SOAP service .

Automatic Activity Manager – the activity manager is responsible for the optimal execution of automatic activities. In the case of a large number of such activities, the Manager creates new threads to handle tasks, trying to minimize downtime in task processing. In order not to block the Manager, each activity has a maximum execution time, after which it is preempted.

Load balancing – during the product operation, the Process Managers compete for the allocation and execution of automatic tasks. This avoids situations in which one Manager is significantly more loaded than the others. Additionally, in the case of a large number of tasks on one server, it is possible to automatically or manually increase the number of instances of Automatic Action Managers on the same or another, selected server. It is also possible to define Managers in such a way that specific tasks (within the process, within all processes) are processed on a specified server.

Quality parameter management

Managing quality parameters in the area of workflow management systems is still a big challenge. The docuRob ® WorkFlow platform offers the following options for managing quality constraints:

Time dependency modeling – time dependencies can often be defined for a given process. In workflow management systems, there are basically two types of time dependencies: execution time or due date .

Notification of exceeding time limits – in the event that a given time limit is exceeded (e.g. the order execution time is 5 days instead of 4), the docuRob® WorkFlow process will notify authorized users (e.g. via e-mail) about the situation, allowing them to perform corrective actions (e.g. changing the salesperson responsible for order execution, skipping the stage of verifying commercial conditions, etc.). The notified persons are designated in a similar way to the executors of the actions.

Identification of delays belonging to the critical path - docuRob® WorkFlow is able to identify whether a given delay of an activity is critical for (an instance of) the process. This allows for quick determination of critical points that affect the execution of the entire process.

Event handling

Apart from standard flow control within the process docuRob® WorkFlow supports flows related to events. Events they can concern both surroundings, How and alone processes performed In product. IN within this area system provides following functionalities:

Action pick up events - In definition process you can define, That given action will be she was expecting on event. IN within specifications events I give myself type events, and other That's possible attributes events such How type process, Whether identifier document, on thing whose he was left launched given process (his instance).

Action of sending an event - in the definition process you can define, That a given activity will be she sent event to the pending actions of receiving the event within this or others performed processes. Thanks ago to the mechanism you can to express necessary synchronization occurring between various instances processes. IN within specifications events I give myself type events , and other That's possible attributes events such such as process type , Whether document identifier , on thing whose he was left launched given process (his instance).

Handling events generated by processes - often exists need, To send down others systems information about specific events related With performing processes. An example of this events Is information about interruption process, which may cause necessity changes status matters or start-up another process. Possible Is definition Yes called recipients events. Processes Receipt events are notified By docuRob® WorkFlow about​ performed tasks and they can to react in appropriate For myself way.

The extended event model compliant with BPMN v. 2.02 notation is discussed in the appropriate chapters of the documentation.

Monitoring and Administration

Another one important group services delivered By docuRob® WorkFlow​ pertain to monitoring and administration of performed processes. The available services allow to:

Check the status of process execution.. - For any process docuRob® WorkFlow makes available information about performed/done work. Information is presented either in a graphic or textual form.

Search processes and activities - Search includes rich set of process instance attributes and activities such as name participants , start date , status delays . For example, by use of the search function you can check, which tasks influence or delay the whole process.

Interrupt a process/activity instance - process interruption results in interruption of all performed activities,

Modification of time limits - on level of process and activities one can modify deadline and maximum time of completion,

Setting priorities and dynamic change of priorities- in the system it is possible to set priorities during the process definition. Available values are: lowest, low, normal, high and highest. During the process execution, the user has the right to change the priority of the activity task to a higher one.

Workflow Process Definition Structure

The structure of a business process definition includes, in addition to the graphical notation elements discussed above along with execution options and the BPQL language, a description of external resources used within the business process and the values of input parameters passed to it when its instance is started.

The basic elements of each process are, apart from the process graph modeled in accordance with the BPMN v. 2.02 notation, such elements as the process memory and the information object , for example a document , handled by the process. The process container constituting the business process instance memory includes values entered into the process as instance initiation parameters, and variables processed and used by business rules defined in the BPQL language. This language can also be used to directly process metadata and the content of the information object .

The set of information that controls the execution of a process also includes data on the roles of potential process participants and their mutual relationships and dependencies. Such information is a standard element of the process domain ontology model , which may also include any concepts and relationships used to model the context of the process processing domain.

Within the docuRob® WorkFlow software tool , we use the Ontology Manager module based on the Topic Maps ontological standard (ISO/IEC 13250:2002) . The Topic Maps data model allows for mapping arbitrarily complex domain areas supported by business processes. TMSL (Topic Maps Scripting Language) is used to create and process domain ontology model data. The scripting language is used to set the appropriate metadata values of the information object or, as in the examples discussed below, to pass the appropriate data directly to BPQL queries.

Example

An important stage in the design of IT systems implemented in accordance with the process architecture is the modeling of work processes due to their key importance for the coordination and automation of task flow between functional teams of the organization and the integration of existing data resources and IT services.

The presented example of modeling work processes created with the use of the docuRob® WorkFlow platform tools and the BPMN 2.02 graphical notation is a key element of the IT system design and implementation cycle, constituting a platform for understanding and agreements between future system users and process designers.

The discussed example presents a model for handling the order process in a company producing industrial robots. Figure 1 and Figure 2 present the Order process model and its Cost of Execution Analysis sub-process model, respectively . For a better illustration of the proposed process solutions, we also present the course of execution of the modeled processes presented as a graph of the history of execution of process instances.

The adopted convention of representing the roles of process task executors by marking them with colors allows us to build a process graph in accordance with the principle of left to right/top to bottom instead of using lanes notation . The result is a much clearer process models. The roles of the task performers in the process model are described in the legend located in the lower left corner of the graph .

The process models were developed using the process design tool of the docuRob® WorkFlow platform compliant with the BPMN 2.02 graphical notation. The execution of process instances representing alternative process flow paths are presented in Figure 4 to Figure 11 as execution history graphs generated by the docuRob® WorkFlow process monitoring services .

The Order business process ( Figure 1 ) supports three types of orders concerning: purchase of a complete product , purchase of spare parts or purchase of services . Within each of the above options, the process manages different paths corresponding to different business situations. A high level of automation of procedures was adopted, supported by the integration of various production management modules (ERP) and by the use of intelligent services implemented by automatic activities calling external AI services (activity Verification of ordering data ) and the BPQL business rules model (activity Analysis of order requirements ).

Order type is represented in the model as an event handled by an event-driven gateway that selects the process path for the Parts , Product or Service event, respectively . Within the process, common procedures have been designed that are handled by an event-driven subprocess ( Invoice Issue subprocess ) and the action of sending a message to the customer placing the order (action to the Customer: refusal to fulfill ).

Invoice Issue subprocess is executed for each of the options of the serviced order . The subprocess ends the process with a final event throwing " Completion ". The execution of the subprocess is initiated by an intermediate event throwing " Signal " located on the process paths corresponding to all three order options.

Action to the Customer: refusal to perform can be performed for the Part or Service order options preceding the process closure with the final event throwing " Error " - Order not confirmed" . The action is initiated by an intermediate interrupting boundary event " Timer " waiting for the Customer to perform the Order Confirmation action or when the ERP system determines (the " Check parts availability " action) that the list of ordered parts cannot be completed.

In the case of the "Product" order option , it was assumed in the process model that the product order can be rejected either as a result of a negative completion ( the " Error " boundary event ) of the " Analysis of implementation cost " subprocess due to an error in the order specification ( the " Error " final throwing event ) or in the event of a failure of contract negotiations (the " Negotiation of the product implementation contract " task) and interruption of the order handling process ( the " Interruption " final throwing event ).

The model of the subprocess " Analysis of the implementation cost " ( Figure 2 ) in which after determining the type of the ordered product, the task " Assessment of technical requirements " is performed sequentially for each of the Product components by the appropriate specialist. The subprocess ends after the task " Approval of the quote" is performed with an implied flow to the final event " End " signaling the positive completion of the analysis. In the case of rejection of the analysis result, an error is signaled.

execution history graphs are placed in the document as screenshots. The left side of the screen containing the Activity Status Color Legend is shown in Figure 3 .

Figure 4 to Figure 6 show two variants of the Order process execution for the product order option , while Figure 5 contains the execution graph of the sub-process (activity 53 ), the course of which was the same for both variants.

Figure 7 to Figure 8 show two variants of the Order process execution for the parts purchase option, and Figure 9 to Figure 11 show three variants of the Order process execution for the service purchase option.

Figure 1. Process model - Order

Figure 2. Sub-process model - Cost of implementation analysis

Figure 3. Color legend of the activity statuses of the process execution history graph

Figure 4. Order - purchase of product_1

The last activity of the process path is the final event " Completion " which causes the instance to end by interrupting the handling of all activities regardless of their current state. In the analyzed process instance , all events that were waiting for the possibility of execution after receiving a token or meeting a defined condition were interrupted . Dashed boundarys and gray filling of activity symbols mean that they have not yet received a token enabling their execution.

Figure 5. Cost analysis of implementation - purchase product_1A

The process instance ended correctly after executing three consecutive instances of task 4 and successfully completing task 6. Since the order was not rejected, the process selected the outgoing transition from activity 6 to the End activity closing the path and the entire process instance.

Figure 6. Order - purchase of product_2

Order process path ( Product option ) representing the case of expected execution ( happy path ) without the need to handle unexpected cases (exception ) ended with the issuance of an invoice and the execution of the final " Terminate " activity .

Figure 7. Order - purchase of spare parts_1

After performing activity 10 (API_ERP service) it turned out that the list of ordered parts could not be completed. The appropriate information was passed to the Client (activity 19 ) and the process instance was ended with the final event " Error "

Figure 8. Order - purchase of spare parts_2

The Order process instance ended with the expected path after Order Delivery (task 34 ) and Invoice Issue. In order to maintain the readability of the process model, intermediate events (throwers and listeners, respectively) of the Link type were used .

Figure 9. Order - purchase of service_1

After the automatic execution in the ERP system (activity 11 ) of the Estimation of time and costs of the service and the execution of the task Development of the project schedule (task 44 ) by the Seller , the waiting time for the execution of the Confirmation of the order by the customer (task 49 ) is started. The " Stopwatch " event has been set to the acceptable waiting time for the Confirmation orders . After the modeled time period has elapsed, the " Stopwatch " event passes the exception transition marker to activity 19. After sending the information to the Client, the process is completed.

Figure 10. Order - Order - purchase of service_2

This variant of the process instance execution illustrates a situation in which the service project execution has been started (activity 21 ) and the marker has been passed to the Condition event . After the project completion condition has been met, the process path will continue. The event has been marked as an activity conditioning the completion date of the process instance.

Figure 11. Order - purchase of service_3

The expected process path was executed and the “ Terminate ” event completed the processing of the process instance after the invoice was issued.